Hi @poliorcetics,

Thanks for this PR, hope it will be merged soon.
Quick question. I just built from it but all I get the change hash in the status line but no diff indicators in the gutter.
Did I miss something?

Hi @poliorcetics,

Thank you for working on integrating jj into helix, I am using helix from your branch, and it has been great so far.

I am new to jj, and this PR is still a draft, but wanted to make a suggestion on the status-line entry,

Will description.first_line() be more useful thanchange_id in the status-line message?

Change-Id:

Description:

I am new to jj, and this PR is still a draft, but wanted to make a suggestion on the status-line entry,

Will description.first_line() be more useful thanchange_id in the status-line message?

It could easily be done code-wise, but I'm trying to get the same behavior as the git backend (to make it easier for this PR to get in), so I don't think I'll do it

If maintainers confirm it would be ok to add, I'll do it :)

This gets a bit weird with reloading newly-added or untracked files.

1. Create a new file, add some content. Nothing shows up in the gutter (expected).
2. Reload the file with :reload. Still nothing in gutter (expected).
3. Edit the file. Edits show up as changes (unexpected!!)

Each time the file is reloaded, the diff base is set to the current file.

I have somewhat of a fix for this at d4a0e44. If the file is untracked, return early. If the file is new, return an empty base. Otherwise, continue as before.

I'm not really a fan of my implementation, since it relies on jj emitting a warning message if the file isn't found in the repo. Could do without that by doing a separate (jj file list).contains(file_relative_to_root), but I didn't want to add another jj invocation.

Was curious to see what an implementation using jj-lib would look like. Have a proof of concept at https://github.com/bryceberger/helix/tree/jj-lib (permalink: a8a105d). Needs better integration with helix's async code, doesn't solve custom backends. Otherwise seems to work.

Looks like this feature doesn't always work.
Often it fails to show any diffs.

I experienced this on a non-collocated repo as well as (albeit less often) on pure Git repos.

I'm not getting any gutter information in a pure JJ repo, and there aren't any logs to suggest something went wrong. Does this PR not provide gutter information? If not could we? I'd be happy to hack on this and see if I can get it going

I'm not getting any gutter information in a pure JJ repo, and there aren't any logs to suggest something went wrong. Does this PR not provide gutter information? If not could we? I'd be happy to hack on this and see if I can get it going

It worked intermittently for me as well.

I suspect it hits some threshold timeout in case the repo is large enough.
You can try to init a blank repo and try it there to check if it's the same issue as I faced.

A small suggestion, to avoid duplicated entries in the change picker in case of conflict:

diff --git a/helix-vcs/src/jj.rs b/helix-vcs/src/jj.rs
index ab0799cdc1..711652dade 100644
--- a/helix-vcs/src/jj.rs
+++ b/helix-vcs/src/jj.rs
@@ -5,6 +5,7 @@
 //! Instead in case there *is* a diff to base ourselves on, we copy it to a tempfile or just use the
 //! current file if not.
 
+use std::collections::HashSet;
 use std::path::{Path, PathBuf};
 use std::process::Command;
 use std::sync::Arc;
@@ -178,12 +179,14 @@
 
     anyhow::ensure!(out.status.success(), "`jj file list` executed but failed");
 
+    let mut conflicted = HashSet::new();
     for entry in split_double_slash(&out.stdout, true) {
         if entry.is_empty() {
             continue;
         }
 
         let path = make_pathbuf(entry);
+        conflicted.insert(path.clone());
 
         if !callback(Ok(FileChange::Conflict { path })) {
             return Ok(());
@@ -257,6 +260,11 @@
             continue;
         };
 
+        // Skip files already reported as conflicted above
+        if conflicted.contains(change.path()) {
+            continue;
+        }
+
         if !callback(Ok(change)) {
             return Ok(());
         }

Recent changes:

• Use the relatively new --no-integrate-operation, which is nicer than --ignore-working-copy because it will immediately find diffs (and everything else) without having to run a jj command outside of Helix, but still without modifying the underlying JJ repo state
• changed_file_picker: made faster by running only one jj command for it
• changed_file_picker: deduplicated conflicted files that have also been modified, directly via the JJ template
• current commit & branch: slightly smarter revset that should be faster to evaluate (pretty much imperceptible except in humongous repositories)

EDIT: oups, there is a bug in that, currently fixing done 🎉

Previously if you reloaded a newly added file, the gutter diff would start being computed from the file on disk, that is not mark the entire file as "added" but sections as "modified" in the gutter.

This is now fixed :)

Fixed a bug with JJ 0.44.0

 error: test failed, to rerun pass `-p helix-term --test integration`

Caused by:
  process didn't exit successfully: `/home/runner/work/helix/helix/target/integration/deps/integration-d67ba11fdaf58aad` (signal: 6, SIGABRT: process abort signal)

This is not the first failure I see like this in Github actions, I saw it in other repos too, I don't think this is something I can fix